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DETAILED ACTION 

1. Applicant's amendment dated January 25, 2008, responding to the Office action 
mailed November 1 , 2007 provided in the rejection of claims 1-3, 5-29, 31-55, and 57- 
78, wherein claim 63 is amended. 

Claims 1-3, 5-29, 31-55, and 57-78remain pending in the application and which 
have been fully considered by the examiner. 

Applicant's arguments with respect to claims rejection have been fully considered but 
are moot in view of the new grounds of rejection - see Kon et al., art made of record, as 
applied hereto. 



Claim Rejections - 35 USC § 103(a) 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 1 02 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

2. Claims 1 -3, 5-1 0,12,14-16,1 8-29, 31 -36, 38, 40-42, 44-55, 57-62, 64, 66-68, 
and 70-78 are rejected under 35 U.S.C. 103(a) as being unpatentable over Gary. D. 
Foster (Pat. No. US 6,675,382 B1 ) (hereinafter 'Foster') in view of Kon et al., 
(Dependence Management in Component-Based Distributed System, January 2000, 
IEEE) (hereinafter 'Kon' - art made of record) 
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3. As to claim 1 (Previously Amended), Foster discloses a method of dynamic 
installation and activation of software packages in a node in a distributed network of 
nodes, the method comprising the computer-implemented steps of: 

• Storing, in a software package storage of a master node in the distributed 
network, a plurality of software packages and a plurality of software modules 
(e.g., Col. 12, Lines 43-52 - the software files required for installation may be 
directly downloaded from the remote server onto the local client system; a set of 
database files to track information pertaining to software packages that have 
been installed or distributed) that the nodes in the distributed network will be 
using (e.g., Col. 1 0, Line 64 through Col. 1 1 , Line 4 - an older release); 

• wherein each software package of the plurality of software packages (e.g., Fig. 2 
- Package; Col. 6, Lines 37-41) contains at least one module (e.g., Col. 7, Lines 
1-9 - payload file contains all files that are required for the installation of 
computer software) and associated dependency information (e.g., Col. 6, Lines 
60-64 - a control file that contains control information pertaining to those files 
and their dependencies); 

• receiving a software update for a node on said master node (e.g., Col. 12, Lines 
43-45); 

• wherein the software update contains a set of one or more software packages 
(e.g., Abstract, Lines 1-5; Col. 3, Lines 46-51; Fig. 2 - Package; Col. 6, Lines 37- 
41); 
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• storing the software update (e.g., Col. 12, Lines 43-45) on said software package 
storage (e.g., Col. 12, Lines 43-45); 

• wherein said master node passes said node identities of one or more software 
packages to be updated (i.e., Col. 8, Lines 34-36) and module dependencies 
(e.g., Col. 8, Lines 22-24); 

Further, Foster discloses a method and apparatus for packing and distributing 
software (e.g., Abstract, Lines 1-2) and check dependencies (e.g., Fig. 4 - element 410 
"Check Dependencies"; Col. 9, Lines 24-26 - At step 410, prior to installing package 
200, any dependencies are checked as specified by...), but does not explicitly disclose 
that said node determines, using the module dependencies, running processes on said 
node that will be affected by the software update and said master node notifies said 
node that a software update is being requested. 

However, in an analogous art of Dependence Management in Component-Based 
Distributed System, Kon discloses: 

• said master node notifies said node that a software update is being requested 
(e.g., P. 4, Sec. of "Dynamic Dependencies", 1 st Par. - In our model, a 
component configurator manages each component , the component configurator 
is responsible for storing the runtime dependencies between a specific 
component and other system and application components ...); and 

• said node determines, using the module dependencies, running processes on 
said node that will be affected by the software update (e.g., Fig. 2 - Reification of 
component dependence; Fig. 4 - Methods for specifying dependencies and 



Application/Control Number: 10/726,067 Page 5 

Art Unit: 2192 

sending events; P. 4, Sec. of "Dynamic Dependencies", 1 st Par. - ... a component 
configurator might be able to refer to components running on a single address 
space, on different address space, and processes, or event on different 
machines in a distributed system . Figure 2 depicts the dependencies that a 
component configurator reifies). 
Therefore, it would have been obvious to one of ordinary skill in the art, at the time 
the invention was made to combine the teachings of Kon into the Foster's system to 
further provide that said node determines, using the module dependencies, running 
processes on said node that will be affected by the software update and said master 
node notifies said node that a software update is being requested in Foster system. 

The motivation is that it would advantageously enhance the Foster's system by 
taking, advancing and/or incorporating Kon's system which by separating inter- 
component communication from inter-component dependence the Kon's framework is 
independent of the paradigm for inter-component communication; it can be used in 
conjunction with connectors, buses, local method invocations, CORBA, Java® RMI, and 
so forth as once suggested by Kon (i.e., P. 2, embedded page, 4 th Par.) 

4. As to claim 2 (incorporating the rejection in claim 1 ) (Previously Amended), 
Foster discloses a method wherein each module has a binary signature (e.g., Fig. 2, 
element 230 - digital signature file; Col. 1 1 , Lines 61 through Col. 1 2, Line 1 0). 
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5. As to claim 3 (incorporating the rejection in claim 1 ) (Previously Amended), 
Foster discloses a method wherein each node has a list of desired characteristics 
stored on said master node which is compared by said master node to each module in 
the software update to determine which modules in the set of one or more software 
packages should be sent to a node (i.e., Col. 7, Lines 35-38 - OSVERSION and 
PLATFORM fields; Col. 8, Lines 34-36; Col. 1 1 , Lines 28-48). 

6. As to claim 5 (incorporating the rejection in claim 1 ) (Previously Amended), Kon 
discloses a method wherein said node notifies affected processes that the software 
update is being requested; wherein each notified process evaluates the effect that the 
software update will have on its operation; wherein if any of the notified processes 
determine that the software update will degrade or have a negative impact on said 
node's normal operation, the process returns a veto to said node; and wherein if a 
process finds that the software update will have no negative effects, the process returns 
an acceptance of the software update to said node (e.g., P.2, 3 rd Par. - Reification of 
the interactions between system and application components lets system software 
recognize the need for reconfiguration to better support fault tolerance, security, quality 
of service (QoS), and optimization ...; 4 th Par. - Our research builds on ... in software 
architecture, dynamic configuration of distributed system, and QoS Specification ... we 
look at all the different kinds of dependencies that tie each component to other 
application, middleware, and system components ...; P. 6, 3 rd Par. - ... it might be 
necessary to transfer the state from the former to the later ... the underlying engine 
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would simply transfer the state from one component to the other without having to 
interpreter its meaning; 4 th Par. - To replace a component and remove the old version 
safely, we must make sure that no other component will try to contact the component 
being removed. We can achieve this by using a combination of four mechanisms: ....) 

7. As to claim 6 (incorporating the rejection in claim 5) (Previously Amended), Kon 
discloses a method wherein said node waits for all of the notified processes to return 
results of their evaluations and once all of the processes have reported to said node, 
said node notifies said master node if any of the processes have vetoed the software 
update (e.g., P. 2, 3 rd Par. - Reification of the interactions between system and 
application components lets system software recognize the need for reconfiguration to 
better support fault tolerance, security, quality of service (QoS), and optimization 4 th 
Par. - Our research builds on ... in software architecture, dynamic configuration of 
distributed system, and QoS Specification ... we look at all the different kinds of 
dependencies that tie each component to other application, middleware, and system 
components P. 6, 3 rd Par. - ... it might be necessary to transfer the state from the 
former to the later ... the underlying engine would simply transfer the state from one 
component to the other without having to interpreter its meaning; 4 th Par. - To replace a 
component and remove the old version safely, we must make sure that no other 
component will try to contact the component being removed. We can achieve this by 
using a combination of four mechanisms: ....) 
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8. As to claim 7 (incorporating the rejection in claim 6) (Previously Amended), 
Foster discloses a method wherein if said master node receives an acceptance from 
said node then said master node sends the set of one or more software packages (e.g., 
Col. 12, Lines 43-45 - the software files required for installation may be directly 
downloaded from the remote server onto the local client system) for the software update 
from said software package storage means (e.g., Col. 12, Lines 43-45 - the software 
files required for installation may be directly downloaded from the remote server onto 
the local client system) to said node (e.g., Col. 12, Lines 43-45). 

9. As to claim 8 (incorporating the rejection in claim 7) (Original), Kon discloses a 
method wherein said node immediately runs software package modules, by loading the 
modules from the software package(s) and signals processes that are being replaced 
by the modules and the affected processes that the changeover is going to occur; 
wherein when all of the signaled processes indicate that they are ready and waiting for 
the changeover, said node starts new modules and signals the affected processes that 
the changeover has occurred; wherein each module starts without affecting normal 
operation of said node; and wherein each affected process restarts, if required, without 
affecting normal operation of said node (e.g., P.2, 3 rd Par. - Reification of the 
interactions between system and application components lets system software 
recognize the need for reconfiguration to better support fault tolerance, security, quality 
of service (QoS), and optimization ...; 4 th Par. - Our research builds on ... in software 
architecture, dynamic configuration of distributed system, and QoS Specification ... we 
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look at all the different kinds of dependencies that tie each component to other 
application, middleware, and system components P. 6, 3 rd Par. - ... it might be 
necessary to transfer the state from the former to the later ... the underlying engine 
would simply transfer the state from one component to the other without having to 
interpreter its meaning; 4 th Par. - To replace a component and remove the old version 
safely, we must make sure that no other component will try to contact the component 
being removed. We can achieve this by using a combination of four mechanisms: ....) 

10. As to claim 9 (incorporating the rejection in claim 8) (Previously Amended), 
Foster discloses a method wherein said node continues with normal operations and 
notifies said master node that it has completed the software update; and wherein said 
master node checks the module dependencies to ensure that any inter-nodal and intra- 
node dependencies are complete (e.g., Fig. 4, step - Check Dependencies; Col. 9, 
Lines 18-33). 

11. As to claim 10 (incorporating the rejection in claim 9) (Original), Foster discloses 
a method wherein if there are any discrepancies in the inter-nodal and intra-node 
dependencies (e.g., Fig. 4, step 410 - Check Dependencies; Col. 8, Lines 27-29), then 
said master node notifies a user (e.g., Fig.4, step 425; Col. 9, Lines 23-28; Col. 10, 
Lines 10-14). 
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12. As to claim 12 (incorporating the rejection in claim 7) (Currently Amended), 
Foster discloses a method wherein said node extracts version information (e.g., Col. 8, 
Lines 17-21) and dependency information (e.g., Col. 8, Lines 22-29) from the set of one 
or more software packages and stores the information in its local persistent storage 
(e.g., Fig. 1, element 112 - Mass Storage; Col. 6, Lines 15-19). 

13. As to claim 14, please refer to claim 8 as set forth above accordingly. 

14. As to claims 15-16, please refer to claims 9-10 as set forth above accordingly. 

15. As to claim 18 (incorporating the rejection in claim 6) (Previously Amended), 
Kon discloses a method wherein if said master node receives a veto from said node, 
then said master node does not update said node and notifies a user that the software 
update will adversely affect said node (e.g., P.2, 3 rd Par. - Reification of the interactions 
between system and application components lets system software recognize the need 
for reconfiguration to better support fault tolerance, security, quality of service (QoS). 
and optimization ...; 4 th Par. - Our research builds on ... in software architecture, 
dynamic configuration of distributed system, and QoS Specification ... we look at all the 
different kinds of dependencies that tie each component to other application, 
middleware, and system components . . . ; P. 6, 3 rd Par. - . . . it might be necessary to 
transfer the state from the former to the later ... the underlying engine would simply 
transfer the state from one component to the other without having to interpreter its 



Application/Control Number: 10/726,067 Page 1 1 

Art Unit: 2192 

meaning; 4 th Par. - To replace a component and remove the old version safely, we 
must make sure that no other component will try to contact the component being 
removed. We can achieve this by using a combination of four mechanisms: ....) 

16. As to claim 19 (incorporating the rejection in claim 18) (Previously Amended), 
Foster discloses a method further comprising receiving an indication to continue 
updating said node, wherein said master node forces said node to accept the software 
update (e.g., Col. 10, Lines 40-47). 

1 7. As to claim 20 (incorporating the rejection in claim 1 ) (Previously Amended), 
Foster discloses a method further comprising initiating the software update by receiving 
an image containing the software update onto said master node (e.g., Col. 1 , Lines 30- 
34). 

18. As to claim 21 (incorporating the rejection in claim 20) (Previously Amended), 
Foster discloses a method receiving an indication of a set of nodes and a set of 
software packages that are to be updated (e.g., Fig. 2 - Package; Col. 6, Lines 37-41). 

19. As to claim 22 (incorporating the rejection in claim 1) (Original), Foster discloses 
a method wherein the software update contains a list of nodes to be updated (e.g., Col. 
1, Lines 7-8,25-30). 
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20. As to claim 23 (incorporating the rejection in claim 1) (Original), Foster discloses 
a method wherein the software update contains a list of software packages destined for 
each node (e.g., Col. 3, Lines 46-51; Fig. 2 - Package; Col. 6, Lines 37-41). 

21 . As to claim 24 (incorporating the rejection in claim 1 ) (Previously Amended), 
Foster discloses a method wherein the master node has an ability to categorize nodes 
into classes where all of the nodes in a particular class of nodes have a same software 
configuration (i.e., Col. 8, Lines 34-38 - OSVERSION) and may have differing processor 
types (i.e., Col. 8, Lines 34-38 - PLATFORM). 

22. As to claim 25 (incorporating the rejection in claim 1 ) (Previously Amended), 
Foster discloses a method wherein a software package of the plurality of software 
packages contains version information (e.g., Col. 8, Lines 17-21), dependency 
information (e.g., Col. 8, Lines 22-24), and other metadata information pertaining to 
software in the package (Col. 8, Lines 12-55). 

23. As to claim 26 (incorporating the rejection in claim 25) (Previously Amended), 
Foster discloses a method wherein the other metadata information includes a list of 
application program interface (API) providers and consumers (e.g., Col. 8, Lines 30-32 
- MAINTAINER field; Col. 10, Lines 56-60). 
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24. As to claim 27 (Previously Amended), Foster discloses a computer-readable 
storage medium carrying one or more sequences of instructions for dynamic installation 
and activation of software packages in a node in a distributed network of nodes, which 
instructions, when executed by one or more processors, cause the one or more 
processors to carry out the steps of: 

• Storing, in a software package storage of a master node in the distributed 
network, a plurality of software packages and a plurality of software modules 
(e.g., Col. 12, Lines 43-52 - the software files required for installation may be 
directly downloaded from the remote server onto the local client system; a set of 
database files to track information pertaining to software packages that have 
been installed or distributed) that the nodes in the distributed network will be 
using (e.g., Col. 1 0, Line 64 through Col. 1 1 , Line 4 - an older release); 

• wherein each software package of the plurality of software packages (e.g., Fig. 2 
- Package; Col. 6, Lines 37-41 ) contains at least one module (e.g., Col. 7, Lines 
1-9 - payload file contains all files that are required for the installation of 
computer software); 

• receiving a software update for a node on said master node (e.g., Col. 12, Lines 
43-45); 

• wherein the software update contains a set of one or more software packages 
(Abstract, Lines 1-5; Col. 3, Lines 46-51; Fig. 2 - Package; Col. 6, Lines 37-41); 

• storing the software update (e.g., Col. 12, Lines 43-45) on said software package 
storage (e.g., Col. 12, Lines 43-45); 
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• wherein said master node passes said node identities of one or more software 
packages to be updated (i.e., Col. 8, Lines 34-36) and module dependencies 
(e.g., Col. 8, Lines 22-24). 

Further, Foster discloses a method and apparatus for packing and distributing 
software (e.g., Abstract, Lines 1-2) and check dependencies (e.g., Fig. 4 - element 410 
"Check Dependencies"; Col. 9, Lines 24-26 - At step 410, prior to installing package 
200, any dependencies are checked as specified by...), but does not explicitly disclose 
that said node determines, using the module dependencies, running processes on said 
node that will be affected by the software update and said master node notifies said 
node that a software update is being requested. 

However, in an analogous art of Dependence Management in Component-Based 
Distributed System, Kon discloses: 

• said master node notifies said node that a software update is being requested 
(e.g., P. 4, Sec. of "Dynamic Dependencies", 1 st Par. - In our model, a 
component configurator manages each component , the component configurator 
is responsible for storing the runtime dependencies between a specific 
component and other system and application components ...); and 

• said node determines, using the module dependencies, running processes on 
said node that will be affected by the software update (e.g., Fig. 2 - Reification of 
component dependence; Fig. 4 - Methods for specifying dependencies and 
sending events; P. 4, Sec. of "Dynamic Dependencies", 1 st Par. - ... a component 
configurator might be able to refer to components running on a single address 
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space, on different address space, and processes, or event on different 

machines in a distributed system . Figure 2 depicts the dependencies that a 

component configurator reifies). 
Therefore, it would have been obvious to one of ordinary skill in the art, at the time 
the invention was made to combine the teachings of Kon into the Foster's system to 
further provide that said node determines, using the module dependencies, running 
processes on said node that will be affected by the software update and said master 
node notifies said node that a software update is being requested in Foster system. 

The motivation is that it would advantageously enhance the Foster's system by 
taking, advancing and/or incorporating Kon's system which by separating inter- 
component communication from inter-component dependence the Kon's framework is 
independent of the paradigm for inter-component communication; it can be used in 
conjunction with connectors, buses, local method invocations, CORBA, Java® RMI, and 
so forth as once suggested by Kon (i.e., P. 2, embedded page, 4 th Par.) 

25. As to claims 28-30, please refer to claims 2-4 as set forth above accordingly. 

26. As to claims 31-32, please refer to claims 5-6 as set forth above accordingly. 

27. As to claim 33, please refer to claim 7 as set forth above accordingly. 

28. As to claim 34, please refer to claim 8 as set forth above accordingly. 
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29. As to claims 35-36, please refer to claims 9-10 as set forth above accordingly. 

30. As to claim 38, please refer to claim 12 as set forth above accordingly. 

31 . As to claim 40, please refer to claim 8 as set forth above accordingly. 

32. As to claims 41-42, please refer to claims 9-10 as set forth above accordingly. 

33. As to claim 44, please refer to claim 18 as set forth above accordingly. 

34. As to claims 45-46, please refer to claims 19-20 as set forth above accordingly. 

35. As to claims 47-52, please refer to claims 21-26 as set forth above accordingly. 

36. As to claim 53 (Previously Amended), an apparatus, comprising: 

• a master node (e.g., Fig. 1 , element 126 - Server; Col. 6, Lines 8-19 - remote 
server computer might transmit a requested code for an application program 
through internet, local network and communication interface); 

• means for storing, in a software package storage of the master node, a plurality 
of software packages and as plurality of software modules (e.g., Col. 12, Lines 
43-52 - the software files required for installation may be directly downloaded 
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from the remote server onto the local client system; a set of database files to 
track information pertaining to software packages that have been installed or 
distributed) that nodes in a distributed network will be using (e.g., Col. 10, Line 
64 through Col. 1 1 , Line 4 - an older release); 

• wherein each software package of the plurality of software packages contains 
(e.g., Fig. 2 - Package; Col. 6, Lines 37-41 ) at least one module (e.g., Col. 7, 
Lines 1-9 - payload file contains all files that are required for the installation of 
computer software); means for receiving a software update for a node on said 
master node (e.g., Col. 12, Lines 43-45); 

• wherein the software update contains a set of one or more software packages 
(e.g., Abstract, Lines 1-5; Col. 3, Lines 46-51 ; Fig. 2 - Package; Col. 6, Lines 37- 
41); 

• means for storing the software update (e.g., Col. 12, Lines 43-45) on said 
software package storage (e.g., Col. 12, Lines 43-45); 

• wherein said master node passes said node identities of one or more software 
packages to be updated (i.e., Col. 8, Lines 34-36) and module dependencies 
(e.g., Col. 8, Lines 22-24). 

Further, Foster discloses a method and apparatus for packing and distributing 
software (e.g., Abstract, Lines 1-2) and check dependencies (e.g., Fig. 4 - element 410 
"Check Dependencies"; Col. 9, Lines 24-26 - At step 410, prior to installing package 
200, any dependencies are checked as specified by...), but does not explicitly disclose 
that said node determines, using the module dependencies, running processes on said 
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node that will be affected by the software update and said master node notifies said 
node that a software update is being requested. 

However, in an analogous art of Dependence Management in Component-Based 
Distributed System, Kon discloses: 

• said master node notifies said node that a software update is being requested 
(e.g., P. 4, Sec. of "Dynamic Dependencies", 1 st Par. - In our model, a 
component configurator manages each component , the component configurator 
is responsible for storing the runtime dependencies between a specific 
component and other system and application components ...); and 

• said node determines, using the module dependencies, running processes on 
said node that will be affected by the software update (e.g., Fig. 2 - Reification of 
component dependence; Fig. 4 - Methods for specifying dependencies and 
sending events; P. 4, Sec. of "Dynamic Dependencies", 1 st Par. - ... a component 
configurator might be able to refer to components running on a single address 
space, on different address space, and processes, or event on different 
machines in a distributed system . Figure 2 depicts the dependencies that a 
component configurator reifies). 

Therefore, it would have been obvious to one of ordinary skill in the art, at the time 
the invention was made to combine the teachings of Kon into the Foster's system to 
further provide that said node determines, using the module dependencies, running 
processes on said node that will be affected by the software update and said master 
node notifies said node that a software update is being requested in Foster system. 
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The motivation is that it would advantageously enhance the Foster's system by 
taking, advancing and/or incorporating Kon's system which by separating inter- 
component communication from inter-component dependence the Kon's framework is 
independent of the paradigm for inter-component communication; it can be used in 
conjunction with connectors, buses, local method invocations, CORBA, Java® RMI, and 
so forth as once suggested by Kon (i.e., P. 2, embedded page, 4 th Par.) 

37. As to claims 54-56, please refer to claims 2-4 as set forth above accordingly. 

38. As to claims 57-58, please refer to claims 5-6 as set forth above accordingly. 

39. As to claim 59, please refer to claim 7 as set forth above accordingly. 

40. As to claim 60, please refer to claim 8 as set forth above accordingly. 

41 . As to claims 61-62, please refer to claims 9-10 as set forth above accordingly. 

42. As to claim 64, please refer to claim 12 as set forth above accordingly. 

43. As to claim 66, please refer to claim 8 as set forth above accordingly. 



44. 



As to claims 67-68, please refer to claims 9-10 as set forth above accordingly. 
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45. As to claim 70, please refer to claim 18 as set forth above accordingly. 

46. As to claims 71-72, please refer to claims 19-20 as set forth above accordingly. 

47. As to claims 73-78, please refer to claims 21-26 as set forth above accordingly. 

48. Claims 11, 13, 17, 37, 39, 43, 63, 65, and 69 are rejected under 35 U.S.C. 103(a) 
as being unpatentable over Foster in view of Kon and in further view of Moshir et al., 
(Pub. No. US 2004/0003266 A1 ) (hereinafter 'Moshir') 

49. As to claim 11 (incorporating the rejection in claim 8) (Previously Amended), 
Foster and Kon do not explicitly disclose a method further comprising storing, in the 
software package storage, older versions of the software packages and the software 
modules that are kept for regressing said node back to a previous module or software 
package version, wherein when said node does not store the set of one or more 
software packages in its local persistent storage, then said node can later regress back 
to previous modules stored in the local persistent storage if it restarts or said master 
node tells it to regress. 

However, in an analogous art of non-invasive automatic offsite patch 
fingerprinting and updating system and methods, Moshir discloses a method further 
comprising storing, in the software package storage, older versions of the software 
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packages and the software modules that are kept for regressing said node back to a 
previous module or software package version, wherein when said node does not store 
the set of one or more software packages in its local persistent storage, then said node 
can later regress back to previous modules stored in the local persistent storage if it 
restarts or said master node tells it to regress (e.g., Abstract, Lines 6-9 - when a failure 
is detected, the rollout is stopped and the software can be automatically removed from 
those computers that already were updated; [0019], Lines 4-7; [0030], Lines 6-13 - if 
the package has been installed on more than one computer, they all can be removed). 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Moshir into the Foster-Kon's 
system to further provide a method further comprising storing, in the software package 
storage, older versions of the software packages and the software modules that are 
kept for regressing said node back to a previous module or software package version, 
wherein when said node does not store the set of one or more software packages in its 
local persistent storage, then said node can later regress back to previous modules 
stored in the local persistent storage if it restarts or said master node tells it to regress in 
Foster-Kon system. 

The motivation is that it would enhance the Foster-Kon's system by taking, 
advancing and/or incorporating Moshir's system which facilitates software deployment, 
software installation, software updating.... Across multiple operating systems and 
devices, across a network as once suggested by Moshir (i.e., [0020]). 
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50. As to claim 13 (incorporating the rejection in claim 12) (Previously Amended), 
Foster discloses digital signature file (e.g., Fig. 2, element 230 - Digital Signature File) 
but both Foster and Kon do not explicitly disclose method wherein said node compares 
binary signatures of modules in the set of one or more software packages with 
corresponding modules stored in the local persistent storage to discover which modules 
have been updated; wherein any binary signatures that match indicate that the module 
has not changed; and wherein any modules that have different binary signatures 
replace the corresponding modules stored in the local persistent storage. 

However, in an analogous art of non-invasive automatic offsite patch 
fingerprinting and updating system and methods, Moshir discloses method wherein said 
node compares binary signatures of modules in the set of one or more software 
packages with corresponding modules stored in the local persistent storage to discover 
which modules have been updated; wherein any binary signatures that match indicate 
that the module has not changed; and wherein any modules that have different binary 
signatures replace the corresponding modules stored in the local persistent storage 
(e.g., Fig. 9, elements 908 - Existence Test , 910 - Signature Block; [0090] - an 
existence test which can use the signature block information to determine if a specific 
patch has been loaded on a machine; [0092]-[0093]; [0106]-[0107]). 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Moshir into the Foster-Kon's 
system to further provide method wherein said node compares binary signatures of 
modules in the set of one or more software packages with corresponding modules 
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stored in the local persistent storage to discover which modules have been updated; 
wherein any binary signatures that match indicate that the module has not changed; 
and wherein any modules that have different binary signatures replace the 
corresponding modules stored in the local persistent storage in Foster-Kon system. 

The motivation is that it would enhance the Foster-Kon's system by taking, 
advancing and/or incorporating Moshir's system which facilitates software deployment, 
software installation, software updating.... Across multiple operating systems and 
devices, across a network as once suggested by Moshir (i.e., [0020]). 

51 . As to claim 17 (incorporating the rejection in claim 6) (Original), Foster and Kon 
do not explicitly disclose a method wherein if more than one node was being updated, 
the software update will not occur if any node vetoes the software update. 

However, in an analogous art of non-invasive automatic offsite patch 
fingerprinting and updating system and methods, Moshir discloses a method wherein if 
more than one node was being updated, the software update will not occur if any node 
vetoes the software update (e.g., Abstract, Lines 6-9 - when a failure is detected, the 
rollout is stopped and the software can be automatically removed from those computers 
that already were updated; [0019], Lines 4-7; [0030], Lines 6-13 - if the package has 
been installed on more than one computer, they all can be removed). 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Moshir into the Foster-Kon's 
system to further provide a method wherein if more than one node was being updated, 
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the software update will not occur if any node vetoes the software update in Foster-Kon 
system. 

The motivation is that it would enhance the Foster-Kon's system by taking, 
advancing and/or incorporating Moshir's system which facilitates software deployment, 
software installation, software updating.... Across multiple operating systems and 
devices, across a network as once suggested by Moshir (i.e., [0020]). 

52. As to claim 37, please refer to claim 11 as set forth above accordingly. 

53. As to claim 39, please refer to claim 13 as set forth above accordingly. 

54. As to claim 43, please refer to claim 17 as set forth above accordingly. 

55. As to claim 63, please refer to claim 11 as set forth above accordingly. 

56. As to claim 65, please refer to claim 13 as set forth above accordingly. 

57. As to claim 69, please refer to claim 17 as set forth above accordingly. 
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Response to Arguments 

58. Applicant's arguments filed on January 25, 2008 have been fully considered but 
they are not persuasive. 

59. Note that examiner does not rely upon Oreizy for teaching "a node determines, 
using the module dependencies, running processes on the node that will be affected by 
the software update" (e.g., as recited in claim 1) and other related subjects (e.g., as 
recited in claims 5, 6, 8, and 18), rather Kon, art made of record, instead. 



Conclusion 

60. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ben C. Wang whose telephone number is 571-270- 
1240. The examiner can normally be reached on Monday - Friday, 8:00 a.m. - 5:00 
p.m., EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on 571-272-3695. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Ben C Wang/ 
Examiner, Art Unit 2192 

April 8, 2008 



/Tuan Q. Dam/ 

Supervisory Patent Examiner, Art Unit 2192 



